Lambda the Ultimate

A long (close to two hours) audio presentation about Python's history and philosophy.

LtU readers will find a lot to disagree with (especially in part 2), for instance when Guido discusses dynamic languages and typing. And yet, I think Guido tries to be reasonable, even though I disagree with some of his conclusions.

Be that as it may, this talk provides a useful summary of Python's history, and some idea about the workings of the Python community. Long time readers will remember that I think language communities play an important, yet under appreciated, role in language evolution and success.

(via Keith)

We analyze the source code of production Java open source projects such as Ant, Tomcat and Batik and load that analysis into a java examples database designed for easy searching. You enter the name of a Java API Class.method you want to see example invocations of and click Search.

Nice idea. Looks like a useful resource.

An amusing podcast about, among other things, the programming model appropriate for SOA, and especially whether is should be synchronous or asynchronous.

You'll feel right at home, since the concepts "abstraction" and "state" raise their head quite early into the discussion...

More on Ruby and Rails in this interview.

Rails is becoming the main reason people decide to pick up Ruby, which is something worth pondering. The interaction between a programming language and a very dominant framework, which isn't part of the standard library of language, is quite interesting.

Some quotes from the interview:

Rails is opinionated software. It eschews placing the old ideals of software in a primary position.

One characteristic of opinionated software is the notion of "conventions over configuration." If you follow basic conventions, such as classes are singular and tables are plural (a person class relates to a people table), you're rewarded by not having to configure that link. The class automatically knows which table to use for persistence. We have a ton of examples like that, which all add up to make a huge difference in daily use.

I really like our domain-specific languages. The beauty of specifying relationships with belongs_to, has_one, has_many and has_and_belongs_to_many. The ease of using validations like validates_presence_of :name.

I think Rails feels, smells, and tastes like it does exactly because its very Ruby-like. It plays heavily on the best in Ruby. The blocks, the ease of creating domain-specific languages, and so on.

What has happened, though, is that Active Record has reduced the pain of dealing with the object-relational mismatch to a point where its a lot less appealing to seek alternatives—especially with databases like SQLite that give you the feel of flat text files, but within the context of SQL.

ContextL is a CLOS extension for Context-oriented Programming. Currently, there is no documentation available, but you can find a small test case in the distribution and an introduction to ContextL's features in a first overview paper.

The paper says:

We present ContextL,a language extension for the Common Lisp Object System that allows for Context-oriented Programming. It provides means to associate partial class and method definitions with layers and to activate such layers in the control flow of a running program. When a layer is activated, the partial definitions become part of the program until this layer is deactivated. This has the effect that the behavior of a program can be modified according to the context of its use without the need to mention such context dependencies in the affected base program. We illustrate these ideas by describing a way to a)provide different UI views on the same object while b)keeping the conceptual simplicity of OOP that objects know themselves how to behave, in this case how to display themselves. These seemingly contradictory goals can be achieved by separating out class definitions into separate layers instead of separating out the display code into different classes.

Sounds kinda like AOP to me. It intriguings, anyway.

A couple of articles worthy of mention that serve as an introduction to REXX. The first article is a general introduction to REXX, while the second one focuses on using REXX to access DB2 databases. Nothing too involved, but I do enjoy accessible introductory articles, no matter the language.

Laziness Without All the Hard Work. Barzilay and Clements. FDPE 2005

While teaching programming languages courses, we have discovered that an extension to PLT Scheme allows the system to accommodate both lazy and strict evaluation in the same system. Moreover, the extension is simple and transparent. Finally, the simple nature of the extension means that the resulting system provides a rich environment for both lazy and strict programs without modification.

A nice thing about this paper (aside from the fact that it uses the PLT module system) is the careful attention to the relationship between features of the language defined by the interpreter and the features of the defining language.

How I got here was, two recent pieces of writing that made me think heavily were Ruby-centric: Mikael Brockman’s Continuations on the Web and Sam Ruby’s Rails Confidence Builder... So I went and bought Programming Ruby ('Pickaxe' in the same sense that Programming Perl is the 'Camel book')

The conclusion of this piece is that Ruby looks like more than a fad, so LtU readers who still haven't checked it out might want to do so...

Where are the other editors, I wonder?

CODeDOC 2002 was a collection of 'software art' projects. One work, W. Bradford Paley's CodeProfiles.java [requires Java support in browser], is particularly interesting because it shows three different ways in which code is "read". The first, and simplest, is a linear scan through the source (the amber highlighting). Second is the sequence in which code was written (white). Third is the execution flow as the program executes.

It's striking how unrelated these three sequences are. Since temporal sequencing lies at the heart of programming, this struck me as worrying. But then, how should they be related? How should the program's structure and creation be related to its temporal flow? And, of course, how does this relate to the language chosen?

For example: if the code were purely declarative then why would there be any correlation between execution and layout? Is my intuition about the importance of any simple relationship between these flows misguided?

Anyway, it is certainly pretty.

The server hosting LtU crashed on Thursday evening. I took this as an opportunity to migrate LtU over to a server running much newer versions of Linux, Apache, PHP, MySQL etc., which takes care of a major aspect of the long-planned upgrade to the latest version of Drupal. For the moment, we're still running the same version of Drupal, since that upgrade requires some software customizations, which are still in progress.

If you notice any problems with the site which didn't exist before, please post a message here.